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Abstract — The authors describe ongoing efforts hy the 
Avionics Architectures for Exploration (AAE) project chartered 
hy NASA’s Advanced Exploration Systems (AES) Program to 
evaluate new avionics architectures and technologies, provide 
ohjective comparisons of them, and mature selected technologies 
for flight and for use hy other AES projects. The AAE project 
team includes members from most NASA centers and from 
industry. This paper provides an overview of recent AAE efforts, 
with particular emphasis on the wireless technologies being 
evaluated under AES to support human spaceflight. 
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I. Introduction 

The field of Avionics is advancing far more rapidly in 
terrestrial applications than in spaceflight applications. 
Spaceflight Avionics are not keeping pace with expectations 
set by terrestrial experience, nor are they keeping pace with the 
need for increasingly complex automation and crew interfaces 
providing crew autonomy as we move beyond Low Earth 
Orbit. NASA must take advantage of the strides by both space- 
related and terrestrial industries to drive our development and 
sustaining costs down. 

It is the intent of the Avionics Architectures for Exploration 
(AAE) team to develop a common core avionic system that has 
standard capabilities and interfaces, and contains the basic 
elements and functionality needed for any spacecraft. This 
common core will be scalable and tailored to specific missions. 
It will incorporate hardware and software from multiple 
vendors, and be upgradeable in order to infuse incremental 
capabilities and new technologies. It will maximize the use of 
reconfigurable open source software (e.g., Goddard Space 
Flight Center’s (GSFC) Core Flight Software (CFS)). 

The long-term focus is on improving functionality, 
reliability, and autonomy, while reducing size, weight, and 
power. Where possible, the project will leverage terrestrial 
commercial capabilities to drive down development and 
sustaining costs. We will select promising technologies for 
evaluation, compare them in an objective manner, and mature 
them to be available for future programs. Of particular interest 
to the project is the use of wireless technologies, which are the 
primary focus of this paper. 

II. Approach 

The overall approach of the AAE project emphasizes the 
need for testing of multiple alternatives to provide objective 
evaluations of the relative merits of architectures and 


technologies. Technologies selected for evaluation include both 
“legacy” systems (e.g., MIL-STD-1553B), and those included 
in technology roadmaps produced by NASA’s Office of Chief 
Technologist (OCT), Avionics Steering Committee (ASC), and 
Space Communications and Navigation (SCaN) Office. We 
recognize that any future exploration vehicles will likely be 
composed of a cluster of more specialized vehicles deployed at 
different times by various organizations/contractors (perhaps 
from different countries), and that we must address how these 
specialized vehicles interact during all mission phases. 
Although the project is focused on avionics for human 
spaceflight, we are considering technologies applicable for 
both crewed and robotic vehicles. The AAE project emphasizes 
the investigation of human interfaces, more powerful 
processors and network configurations, wireless technologies 
for both networking and instrumentation, and flexible long- 
haul communications technology. 

A. Challenges and Guidelines 

As part of the initial AAE effort, a set of high-level 
challenges and associated architectural guidelines have been 
identified. The challenges are as follows: 

• Future exploration vehicles are undefined, but are likely 
to be an aggregate of multiple vehicles from multiple 
sources. This will drive sparing, redundancy, etc. 

• Size, weight, and power (SWaP) must always be 
minimized. 

• Processing requirements exceed that which can be 
provided by existing space hardened avionics (e.g.. Power 
PC-based Rad750). 

• The radiation environment at high Earth orbit (HEO) and 
beyond is much worse than it is at low earth orbit (LEO). 

• Because of the radiation environment, we cannot rely on 
commercial-off-the-shelf (COTS) hardware for additional 
processing capabilities as NASA has done on Shuttle and 
the International Space Station (ISS) (i.e., laptops are not 
likely to work reliably). 

• Exploration vehicle requirements will change/grow over 
the vehicle’s lifetime, as will the expectations set by 
terrestrial state of the art. We need to accommodate these 
changes without undue expense. 

• A distributed ground development and test architecture 
must be supportable. This requires loosely-coupled 
interfaces between systems. 


The authors would like to acknowledge the support of the AAE sponsors 
at NASA Headquarters: Mr. Jason Crusan (Director, Advance Exploration 
Systems Division) and Mr. Richard McGinnis (Lead, AES Operations 
Domain). 



These high level challenges, along with other project level 

decisions, lead to the following set of architectural guidelines: 

• Minimize Avionics SWaP in the Flight Vehicle. Use 

wireless local area networks (LANs) and sensor networks 
where possible. Use low-power or passive (no power) 
sensors whenever practical. Minimize total wiring on the 
vehicle. Minimize unique components for sparing. 

• Keep the architecture and design modular so we can 
launch incrementally. Allow capabilities to be integrated 
into the vehicle when they are needed, or earlier if it 
makes sense from an available launch mass perspective. 

• Minimize Cost. Use existing capabilities to avoid near- 
term design, development, test, and evaluation (DDT&E). 
Allow for growth using new technology to avoid future 
DDT&E. Allow for infusion of new technology to reduce 
sustaining effort. Look for places where improved 
Avionics can drive down overall vehicle costs. 

• Minimize Risk. Use proven technology for critical 
functions. Use existing capabilities to minimize schedule 
risk. 

• Minimize logistics and maintenance. Pay particular 
attention to the trade-off between utilizing precious 
habitable volume for mounting avionics inside the 
spacecraft versus the effort required for external 
maintenance via extra-vehicular activity (EVA). 

• Support Heterogeneity. We cannot expect every module 
of an aggregate vehicle to be the same. No one 
architecture/design will be an acceptable answer for 
everything. 

• Strive for “Commonality”. This can mean choosing the 
same components/boards/boxes to be used throughout a 
vehicle, ft must mean developing a way for these different 
things to talk to each other, ft should mean making sure 
that things of a similar type can be exchanged to allow for 
minimal sparing. 

• Vehicle backbone network. A high-speed wired LAN 
(e.g., Ethernet) will be available for both crew support 
and as a backbone network for non-critical vehicle data 
transport. 

• Maximize the use of Core Flight Software (CFS). 

Another AES-funded effort at JSC is the Core Flight 
Software (CFS) project. Briefly stated, the Core Flight 
Software project’s objective is to evolve and extend the 
reusability of GSFC’s Core Flight Software System into 
human-rated systems, thus enabling low cost, and rapid 
access to space, ft was decided that the AAE project 
would make maximum use of CFS. This approach should 
maximize our ability to leverage platforms, resources and 
skills from synergetic programs/projects for development 
of next generation human-rated space software systems 
and utilize these products in direct support of 
development and certification of future manned 
programs.Incorporate “Loose” Interfaces. Wireless 
communication interfaces are by nature loosely-coupled 
but usually co-located because they are unwieldy. It is 
sometimes highly desirable to test parts of a vehicle 


“together” while still at the respective vendor facilities. 
For both reasons, internal interfaces must consider how a 
system can be distributed during development, 
integration, and checkout. 

• Use iPAS and F.F. In order fo maximize return on 
investment, the AAE project has made extensive use of 
the Flight Deck of the Future (F.F) and the Integrated 
Power, Avionics, and Software (iPAS) capability 
developed by JSC Engineering. iPAS is a multi-system 
environment where next generation flight systems can be 
tested and demonstrated. It provides multi-mission/multi- 
vehicle simulations, a common set of test services, access 
to a variety of actual sensors and effectors, and access via 
the Distributed Systems Network (DSNet) to capabilities 
at multiple NASA centers'. The F.F focuses primarily on 
the human-machine interface. It allows us to evaluate 
different interface technologies together with personnel 
from Flight Crew Operations, Human Health and 
Performance, and other stakeholders. 

III. Progress to date and current status 

To date, the AAE Project has successllilly demonstrated a 
plausible avionics architecture for a notional habitat and 
waystation located at the L2 Earth-Moon Lagrange point. We 
have also made significant strides toward the goal of a flexible 
avionics architecture that can be used to evaluate Iliture 
concepts/architectures/components for both our nominal L2 
Station and other vehicles [1,2,3]. 

The AAE architecture emphasizes the use of open interface 
standards and reconfigurable open source software. It also 
contains the basic core elements and functionality required for 
any spacecraft while providing scalability and 
reconfigurablility for different missions. The goal is to enable 
integration of hardware from multiple vendors and 
international partners and to provide the capability to evaluate 
and use evolving (near launch) technology. This robust 
architecture will allow us to continuously upgrade our 
capabilities and infuse new technologies with cost effective 
validation. 

Our efforts remain centered on incremental architectural 
upgrades applied to different mission scenarios. These 
upgrades and scenarios are evaluated during periodic 
Integrated Tests (IT’s). To dale, six IT’s have been conducled. 
The remaining sub-sections of Section III describe the goals 
and accomplishments to date for each of our technical Areas of 
Emphasis (AOEs). Details are provided only for AOEs focused 
on wireless technology. The plans and strategies for the Iliture 
are described in Section IV. 

A. Proximity Communications 

As we accept the transformation of the vehicle backbone 
network to Internet Protocol (IP), and vehicle communications 
with the ground become entirely IP packet-based, proximity 
communications comes to mean a wireless extension of the 
wired vehicle backbone network, while radios providing 
backhaul from the vehicle to the ground become gateways to 
the terrestrial networks. 



A number of widely commercialized open standards fulfdl 
sophisticated terrestrial needs for proximity communications. 
These investments can be heavily leveraged to support space 
exploration scenarios. Miniaturized consumer-grade parts often 
have sufficient radiation survivability to be useful. Custoiuarily 
these technologies are manually configuration-managed by the 
Information Technology trade and by users. Technologies of 
distinct interest include Wi-Fi (IEEE 802.1 In, ac), Wi-Gig 
(802.1 lad) and LTE. Overlapping these technologies could 
produce a composite wireless network that provides useful 
coverage beyond 100km at a several Mbps, tapering to many 
Gbps for supporting live video at 100m. 


For space exploration, the network architecture must be 
robust, scalable and extensible over time by a variety of 
vendors, adaptable to unforeseen mission objectives, require 
minimal pre-deployed infrastructure, require minimal crew 
time for maintenance, and be manageable over intermittent 
high-delay communication links. It is therefore important to 
achieve a standards-based autonomous, self-organizing, self- 
healing wireless network based on the principle of cooperative 
communication. [4]. By including nodes with several types of 
communication peripherals each (Wi-Gig, Wi-Fi, LTE), a 
proximity network can be formed of a collection of meshes 
with frequent cross-links. An example of this is illustrated in 
Figure 1. 



Figure 1. Notional Wireless Proximity Mesh Network. 

We must then consider what behavior we want when the 
proximity coverage of two vehicles overlaps. Do the networks 
join? Does that mean the two vehicles become one? Can the 
crew of one see a docking camera on the other? What if the 
vehicles belong to partnered political allies? What can 
applications on one vehicle access on the other? Suppose two 
vehicles dock in LEO under cover of a network of 
geosynchronous satellites, and subsequently depart for deep 
space. They are both mobile and their network service provider 
changes, but does this mean their IP addresses both change? 
Questions like these can be investigated using alternative iPAS 
scenarios and solutions can be informally evaluated using 
iPAS, distributed vehicle assets, and affdiated ground station 
and control center assets. 


B. Wireless Sensing 

Wireless sensing represents a key enabling technology for 
next generation space vehicles. Substantial weight reductions 
may be realized by eliminating the cable runs, cable harnesses, 
and connectors common to wired instrumentation systems in 
modern vehicles and launchers. These weight savings may then 
be applied to increase the capabilities of the vehicle itself or 
permit more vehicle payload, expanding the mission scope. In 
addition, allowing sensors to be entirely free of wires, both for 
power and communication, affords unprecedented flexibility in 
sensor installation. Removing physical interfaces to vehicle 
power and data buses reduces the burden on system integrators, 
especially where bulkhead penetrations are required to route 
cable runs. This can allow sensor installation much later than 
normal in a vehicle’s assembly, integration, and testing phase, 
and it can also allow installation of new instrumentation once a 
vehicle is deployed operationally, in the case of crewed 
systems such as the International Space Station (ISS). The ISS, 
which is well into its second decade of operation and was on 
the drawing board more than a decade prior to the launch of its 
first elements, provides an excellent example of a vehicle 
whose sensing needs late in life could not be anticipated in 
their entirety by its designers. 

Sensing requirements on a vehicle can cover a wide range, 
extending froiu occasional sampling of environmental data 
(such as CO 2 levels in a habitable luodule) for increased 
situational awareness to capturing high-bandwidth waveforms 
(such as accelerometer data) as part of a developmental flight 
instruiuentation (DFI) task to study vehicle performance and 
structural health. Data may be gathered and transiuitted 
periodically according to some set schedule or on demand in 
response to some event such as a micrometeoroid impact. 

As with the other AAE technology areas discussed in this 
paper, we focus on leveraging commercial wireless data 
transport standards and COTS radios as much as possible, 
given the rapid progress made over the last decade in the 
related fields of wireless sensor networks (WSNs) and the 
Internet of Things (loT). Though a number of alternatives are 
on the market, covering a wide gamut of sensing needs, we 
have focused on three distinct protocols thus far: ISAlOO.lla, 
IEEE 802.11 (Wi-Fi), and EPC Global Class 1 Generation 2. 
These three cover a range of applications from very low to very 
high data rates and entail different tradeoffs between 
performance and power consumption. Bluetooth and BEE are 
also finding an entry in the area of wearables, but are not 
treated here. 

ISAlOO.l la-2011, froiu the Industrial Society of 
Automation, describes a reliable, low power, low data-rate, 
multi-hop mesh network. It starts with the 2.4 GHz physical 
(PHY) layer of the IEEE 802.15.4-2006 standard and builds a 
complete protocol stack as described by the Open Systems 
Interconnection (OSI) model. A channel-hopping scheme, 
centrally coordinated by a network management, gives the 
protocol a robustness lacking in the fixed-channel IEEE 
802.15.4 standard and allows the network to adaptively 
contend with time-varying interferers such as other wireless 
systems occupying same band. Thus, it is more appropriate for 
wireless monitoring and control in harsh industrial 




























deployments, and by extension spaceflight applications, than 
plain IEEE 802.15.4 or the derivative ZigBee Pro protocol. [5] 

ISAlOO.lla shares many features in common with the 
similar WirelessHART standard, and it also forms the basis for 
the IEEE 802.15.4e amendment to the 802.15.4 standard. We 
focus on deploying ISAlOO.lla due to the availability of 
VN210 radios from Nivis, EEC and the ease of application- 
layer integration to arbitrary applications, but the results 
generalize. Our choice of ISAlOO.lla is consistent with the 
Consultative Committee for Space Data Systems (CCSDS) 
“Magenta Book” recommendation for low data-rate wireless 
communications for spacecraft monitoring and control [6]. 

To evaluate this standard, we have interfaced the Nivis 
ISAlOO.lla radio to a power supply and Texas Instruments 
MSP430-family microcontroller using a modular form factor 
developed at JSC, similar to that depicted in Figure 2. The 
stack is fitted with a module allowing an interface to a thruster 
pressure transducer, enabling us to monitor thruster firings 
from a bank of cold-gas, computer-controlled jets in the iPAS 
testbed. 



Figure 2: ISAlOO.lla modular wireless seusor uode. 

Although the wireless thruster sensor itself captures frill- 
bandwidth pressure waveforms, thruster firing events are 
summarized before being transmitted over the low data-rate 
ISAlOO.lla network. When a pressure transient is detected (a 
set threshold is exceeded), an “on” message is sent, followed 
by an “off’ message when the transient ends (by a second 
threshold crossing) that contains a summary of the transient 
event consisting of times and pressure readings for the 
starting/ending threshold crossings and the transient peak. 
Sensor nodes communicate with the ISAlOO.lla system 
manager and network gateway, co-located in the iPAS testbed, 
and data is passed to displays in the F.F via a CFS application. 

This ISAlOO.lla application demonstrates use of a low 
data-rate, low-power “active” WSN - so dubbed because the 
radio requires active application of power to communicate. To 
explore high-data rate active wireless sensing, we repeat the 
exercise described above, substituting an IEEE 802.1 In (Wi- 


Fi) compliant, 2.4 GHz COTS radio module from Gainspan for 
the Nivis ISAlOO.lla radio. In this case, the entire thruster 
pressure waveform is transmitted, rather than a simple 3- 
element ordered pair summary, taking advantage of the much 
greater throughput afforded by IEEE 802. 1 1 . 

Finally, we round out our AAE investigation of wireless 
sensing by focusing on so-called “passive” transmission 
schemes. In contrast to the active schemes like ISAlOO.l la and 
IEEE 802.1 In, these passive schemes require no application of 
onboard power to drive the transmitters; rather, they make user 
of power beamed at them by an interrogator to which they then 
send their data. We turn to the EPC Global, Class 1 Generation 
2 Radio Frequency Identification (RFID) protocol, which is 
typically used to track tagged items by their identifier but 
which also has provisions for storing sensor data as well. 

Using a modular approach similar to that described for 
ISAlOO.lla and Wi-Fi, we have assembled a small test unit to 
interface a thermocouple to a serial-writable RFID chip from 
Cypress Semiconductor. Data is sampled by the RFID sensor 
node at a continuous rate and stored to tag memory. Rather 
than requiring immediate transfer of that data to the RFID 
interrogator, we assume the interrogator is a mobile unit which 
may not always be available when a new sample is taken. A 
network overlay inspired by delay tolerant network (DTN) 
techniques manages movement of sensor data between the 
sensor tag and the mobile interrogator; design of that overlay is 
described in detail in the companion paper found in [7]. Data is 
gathered by the mobile interrogator shown in Figure 3 and sent 
to a standalone console in iPAS for display. 



Figure 3: mobile RFID interrogator platform. 

C. Processors, Networks, and Instrumentation (PNI) 

We have successfully loaded CFS on multiple single board 
computers with different operating systems, and we continue to 
add to the combinations we have demonstrated. For the 
primary flight computer in the architecture we have developed 
a method of hot backup. This was demonstrated by the ability 
to simultaneously operate two dissimilar machines running 
dissimilar operating systems over an Ethernet network. This 
capability has been extended to provide a standalone CFS quad 


voting software demonstration that utilizes three unique 
eombinations of proeessor and operating system. In the near 
future, this standalone eapability will be merged with the 
integrated AAE arehiteeture. 

D. Human Interfaces 

We have provided a number of system-level displays for 
use in the Orion Multi-purpose Crew Vehiele (MPCV) eoekpit 
moek-up, and we are now exploring alternative display 
development system teehniques for rapid prototyping and 
testing. We have sueeessfully demonstrated our ability to 
render displays by implementing a radiation tolerant software 
GPU on an AiTeeh C903, and we are in the proeess of porting 
it to an AiTeeh C925 to take advantage of the PCIe bus on this 
board. We are eollaborating with Kennedy Spaee Center 
(KSC) and the University of Florida-led Center for High- 
Performanee Reeonfigurable Computing (CHREC) to identify 
proeessor arehifeetural options for future eonsideration. 

E. Model-Based System Engineering 

NASA has initiated efforts to implement Model-Based 
System Engineering (MBSE). In an effort to gain experienee in 
this area, the AAE projeet adopted MBSE for our referenee 
implementations. In the near-term, MBSE tools provide with 
the flexibility to analyze and doeument a variety of 
arehiteetures and share this information with other AES 
projeets. Ultimately, this will support the AAE goal of 
developing a referenee implementation of the avionies 
arehiteeture(s) that ean be provided to industry (users) as a 
basis for standards and proeurements. 

F. Software Defined Radio and Delay Tolerant Networks 

To support the AAE long range eommunieations 
arehiteeture, we have been exploring the use of software- 
defined radio (SDR) teehnology, in whieh the radio transeeiver 
performs the baseband proeessing funetions entirely in 
software, ineluding modulation/demodulation, error eorreetion 
eoding, and eompression/deeompression. SDR teehnologies 
will be of great benefit to NASA as they allow for inereased 
interoperability, interferenee mitigation, higher speetral 
effieieney, and lower upgrade eosts than applieation-speeifie 
hardware. 

DTN is also a fundamental part of our eommunieations 
arehiteeture. NASA is developing the DTN protoeol suite that 
extends terrestrial internet eapabilities into highly stressed data 
eommunieation environments where eonventional internet 
protoeols do not work well. The DTN protoeol suite is being 
standardized by the Consultative Committee for Spaee Data 
Systems (CCSDS) and all of the DTN protoeols will be 
international standards, supported by open-souree software that 
ean help users implement new eapabilities. 

The development of the DTN protoeol suite is not within 
the seope of the AAE projeet, but we are ineorporating new 
DTN eapabilities as they are developed. More importantly, we 
are performing trade studies to determine the best loeation to 
host DTN within the spaeeeraft arehiteeture, ineluding key 
eonsiderations sueh as size, weight and power, proeessor 
utilization, storage eapaeity, deviee real estate, and required 
data rates. The AAE projeet is also studying the impaet of 
having DTN nodes at other loeations within the end-to-end 


eommunieation arehiteeture, eonsidering faetors sueh as 
network reliability, implementation eosts, and the need for 
international interoperability. 

IV. Future Strategy and Goals 

In fiseal year 2015 (FY15), the AAE Projeet will be 
eombined with the Core Flight Software (CFS) Projeet, the 
DTN Projeet, and Fault Deteetion Isolation and Reeovery 
(FDIR) and Planning aspeets of the Autonomous Mission 
Operations (AMO) Projeet. This new AES projeet will be 
known as the AES Avionies & Software Projeet. The purpose 
of the Avionies & Software projeet is to build a suite of tested 
and reusable avionies and software eomponents that reduee 
eost and risk for future exploration programs and enable 
infusion of new teehnologies and eapabilities into eurrent 
Programs. This projeet will utilize Model-Based Systems 
Engineering tools to eatalog the suite of avionies and software 
eomponents, enabling trade-study analyses and overall system 
design to be easily performed based on mission requirements. 

The top level goals for this projeet are to: 1) develop 
avionies and software arehiteetures that support NASA goals 
for Beyond-LEO exploration “spaee vehieles” that may be 
modular, multi-vendor, and multi-IP eonfigurations, and 2) 
evaluate design eoneepts in a system environment to verify 
ability to integrate diverse interfaees and evaluate system 
performanee. We will be working towards an “open” 
arehiteeture that allows use of hardware from multiple vendors, 
enables use of evolved teehnology, and provides the ability to 
upgrade eapabilities and infuse new teehnologies in a eost 
effeetive manner. 

With respeet to wireless teehnology development and 
infusion, we will eontinue to study proximity eommunieation 
arehiteetures based on heterogeneous multi-hop mesh networks 
The most promising approaehes will be infused into the iPAS 
testbed and evaluated under multiple seenarios in order to 
determine their eapabilities for supporting operations in the 
vieinity of future exploration vehieles and habitats. We will 
eontinue to evaluate both aetive and passive wireless sensor 
networking teehnology and work toward the integration and 
testing of independent wireless subsystems with CFS and with 
vehiele eommand and data handling systems. We will also 
eontinue developmental work on the DTN protoeol suite and 
study sueh aspeets as DTN network administration, seeurity, 
and routing within the AAE framework. 

Although speeifie plans and objeetives are still in- work, we 
intend to evaluate additional arehiteetures providing 
redundaney with dissimilar hardware, fault management and 
advaneed eaution and warning. We will also be simulating 
more dynamie situations sueh as entry, deseent, and landing. 
We will be supporting other AES projeets sueh as Advaneed 
ECLSS and EAM. We expeet that some of our teehnology 
demonstrations will prove useful to both ISS and Orion. 

V. CONCLUSIONS 

During its initial phases, the AAE Projeet has sueeessfully 
demonstrate a plausible avionies arehiteeture for a notional L2 
Station and made signifieant strides toward our goal of a 
flexible avionies arehiteeture that ean be used to evaluate 
future eoneepts/arehiteetures/eomponents for both a nominal 



L2 Station and other vehicles. Our Rev. 2.0 architecture 
provided a common core system that has standard capabilities 
and interfaces, and contains basic core elements and 
functionality needed for any spacecraft. If desired, this system 
could be scaled and tailored to any specified mission. The 
system incorporates hardware from multiple vendors, and 
reusable and reconfigurable open source software (e.g., GSFC 
CFS). 

. The vision for the consolidated FY15 Avionics & 
Software Project includes the development of architectures and 
system designs which can be used for flight programs in both 
the near and long term. 

For the near term, this means that we must provide a point 
solution targeted for an identified mission in 2-3 years. 
Essentially this solution must be a “good enough” answer from 
the options we have, which can be matured for flight with 
minimal effort and used as a basis for procurement 
specifications. 

For the long term, our intent is to build a “catalog” of 
multiple solutions which can be used “mostly off-the-shelf’ for 
a variety of situations. This catalog will include specific 
components and overall architectures. Recognizing that one 
size does not fit all, each will be rated for suitability to 
different mission types. New technologies will be incorporated 
in a timely manner in order to take advantage of strides being 
made by industry to drive program development and sustaining 
costs down. This strategy should allow us to include vehicle 
“hooks and scars” for later augmentation; facilitate component 
repair, replacement, and upgrades; and take advantage of 
schedule slips during the development phase with improved 
hardware. 


We remain committed to demonstrating the technical and 
economic benefits of our approach, but the amount of progress 
we are able to make is dependent on funding and resource 
constraints, along with the priorities set by the Agency for 
Fluman Spaceflight. 

Our team already includes participants from most NASA 
centers and industry, but we recognize the need to widen 
participation from NASA and other government agencies, add 
more industry and academic partners, and begin discussions 
with potential international partners during the coming years. 
We look forward to engaging these future stakeholders. 
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